Also complete cache effects for BINARY_SUBSCR family.

… include a file extension (pythonGH-99542)

…aseException (pythonGH-99572)

There was an extra `>` in the url.

The sentence "Set the LC_CTYPE locale to the user preferred locale." should end with a period
instead of a question mark.

Add some missing links to source from Python docs

…mantics_` (pythonGH-99285)

It was untested and undocumented. No code has been found in the wild that ever used it.

…iables

…them (pythonGH-99215)

Automerge-Triggered-By: GH:lysnikolaou

…on protocol (pythongh-99623)

Describe the multiprocessing connection protocol.

It isn't a good protocol, but it is what it is.  This way we can more
easily reason about making changes to it in a backwards compatible way.

…ines that fill the available buffer (python#99605)

…ors (pythonGH-96893)

Fix a number of compile errors with GCC-12 on macOS:

1. In pylifecycle.c the compile rejects _Pragma within a declaration
2. posixmodule.c was missing a number of ..._RUNTIME macros for non-clang on macOS
3. _ctypes assumed that __builtin_available is always present on macOS

)

os.remove can raise PermissionError instead of IsADirectoryError,
when the object to be removed is a directory (in particular on
macOS).

This reverts a change done in python#14262.

Fix a reference bug in _imp.create_builtin() after the creation of
the first sub-interpreter for modules "builtins" and "sys".

Co-authored-by: Kumar Aditya <59607654+kumaraditya303@users.noreply.github.com>
Co-authored-by: Erlend E. Aasland <erlend.aasland@protonmail.com>

…ythonGH-99664)

…n#99660)

The tests in question were added in 0eec627 by Serhiy. Apparently,
sqlite3 changed exceptions raised in those cases in the mean time but
the tests never ran because they require a high `-M` setting in the
test runner.

…a Python.h (pythonGH-99014)

The ``structmember.h`` header is deprecated, though it continues to be available
and there are no plans to remove it. There are no deprecation warnings. Old code
can stay unchanged (unless the extra include and non-namespaced macros bother
you greatly). Specifically, no uses in CPython are updated -- that would just be
unnecessary churn.
The ``structmember.h`` header is deprecated, though it continues to be
available and there are no plans to remove it.

Its contents are now available just by including ``Python.h``,
with a ``Py`` prefix added if it was missing:

- `PyMemberDef`, `PyMember_GetOne` and`PyMember_SetOne`
- Type macros like `Py_T_INT`, `Py_T_DOUBLE`, etc.
  (previously ``T_INT``, ``T_DOUBLE``, etc.)
- The flags `Py_READONLY` (previously ``READONLY``) and
  `Py_AUDIT_READ` (previously all uppercase)

Several items are not exposed from ``Python.h``:

- `T_OBJECT` (use `Py_T_OBJECT_EX`)
- `T_NONE` (previously undocumented, and pretty quirky)
- The macro ``WRITE_RESTRICTED`` which does nothing.
- The macros ``RESTRICTED`` and ``READ_RESTRICTED``, equivalents of
  `Py_AUDIT_READ`.
- In some configurations, ``<stddef.h>`` is not included from ``Python.h``.
  It should be included manually when using ``offsetof()``.

The deprecated header continues to provide its original
contents under the original names.
Your old code can stay unchanged, unless the extra include and non-namespaced
macros bother you greatly.

There is discussion on the issue to rename `T_PYSSIZET` to `PY_T_SSIZE` or
similar. I chose not to do that -- users will probably copy/paste that with any
spelling, and not renaming it makes migration docs simpler.


Co-Authored-By: Alexander Belopolsky <abalkin@users.noreply.github.com>
Co-Authored-By: Matthias Braun <MatzeB@users.noreply.github.com>

Without releasing the GIL calls to termios APIs might block the entire interpreter.

…ntation (python#99529)

On some platforms, and in particular macOS/arm64, the calling
convention for variadic arguments is different from the regular
calling convention. Add a section to the documentation to document
this.

pythonGH-99422)

…#99655)

Replace "Py_DECREF(var); var = new;" with "Py_SETREF(var, new);"
in longobject.c and _testcapi/long.c.

…unction is modified (python#98175)

Fix potential race condition in code patterns:

* Replace "Py_DECREF(var); var = new;" with "Py_SETREF(var, new);"
* Replace "Py_XDECREF(var); var = new;" with "Py_XSETREF(var, new);"
* Replace "Py_CLEAR(var); var = new;" with "Py_XSETREF(var, new);"

Other changes:

* Replace "old = var; var = new; Py_DECREF(var)"
  with "Py_SETREF(var, new);"
* Replace "old = var; var = new; Py_XDECREF(var)"
  with "Py_XSETREF(var, new);"
* And remove the "old" variable.

Fix potential race condition in code patterns:

* Replace "Py_DECREF(var); var = new;" with "Py_SETREF(var, new);"
* Replace "Py_XDECREF(var); var = new;" with "Py_XSETREF(var, new);"
* Replace "Py_CLEAR(var); var = new;" with "Py_XSETREF(var, new);"

Other changes:

* Replace "old = var; var = new; Py_DECREF(var)"
  with "Py_SETREF(var, new);"
* Replace "old = var; var = new; Py_XDECREF(var)"
  with "Py_XSETREF(var, new);"
* And remove the "old" variable.

Replace "Py_XDECREF(var); var = NULL;" with "Py_CLEAR(var);".

Don't replace "Py_DECREF(var); var = NULL;" with "Py_CLEAR(var);". It
would add an useless "if (var)" test in code path where var cannot be
NULL.

…ngh-100085)

python#81057

…ongh-100203)

We can't move it to _PyRuntimeState because the symbol is exposed in the stable ABI. We'll have to sort that out before a per-interpreter GIL, but it shouldn't be too hard.

python#81057

…efault_scheme (python#100207)

…tizer warning) (python#100215)

…e of code unit. (pythonGH-100223)

…python#100177)

pythongh-100176: Remove redundant compat code for Python 3.2 and older

Python 3.2 has been EOL since 2016-02-20 and 2.7 since 2020-01-01, so we
can remove this old compatibility check and unindent the old else-block.

Also, in the unindented block, replace a .format() call with an f-string.

Plus similar changes in the documentation.

…ncio` docs (python#100249)

…0254)

* move _PyRuntime.global_objects.interned to _PyRuntime.cached_objects.interned_strings (and use _Py_CACHED_OBJECT())
* rename _PyRuntime.global_objects to _PyRuntime.static_objects

(This also relates to pythongh-96075.)

python#90111

…9998)

* Initialize `type_watchers` array to `NULL`s
* Optimize code watchers notification
* Optimize func watchers notification

…100259)

Typo introduced in python#100223.

Automerge-Triggered-By: GH:brandtbucher

…H-100255)

…99928)

… input (python#100205)

The presence of this macro indicates that a particular instruction
may be considered for conversion to a register-based format
(see faster-cpython/ideas#485).

An invariant (currently unchecked) is that `DEOPT_IF()` may only
occur *before* `DECREF_INPUTS()`, and `ERROR_IF()` may only occur
*after* it. One reason not to check this is that there are a few
places where we insert *two* `DECREF_INPUTS()` calls, in different
branches of the code. The invariant checking would have to be able
to do some flow control analysis to understand this.

Note that many instructions, especially specialized ones,
can't be converted to use this macro straightforwardly.
This is because the generator currently only generates plain
`Py_DECREF(variable)` statements, and cannot generate
things like `_Py_DECREF_SPECIALIZED()` let alone deal with
`_PyList_AppendTakeRef()`.

I updated only UNARY_POSITIVE_R to the new format.

- Syntax `register inst(NAME, (ieffects -- oeffects)) { ... }`
- Map stack effects from/to `REG(opargN)` instead of PEEK()
- Use `Py_XSETREF(REG(opargN), result)` for output effects
- Suppress stack adjustment in epilogue
- Suppress effect of `DECREF_INPUTS()`
- Always go to plain `error` in `ERROR_IF()`